Capybara summary for PR 1763

• rec_dis_10x100_minQ2=0_craterlake
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-05-16T13:49-04:00 d7ab982}}

Need a rebase.

There are some changes in the BTOF charge sharing I need to understand/fix and discus whether the changes are actually improvements or not.

There are some changes in the BTOF charge sharing I need to understand/fix and discus whether the changes are actually improvements or not.

What's the problem you're facing, if you don't mind me asking? I think it is a nice improvement over the original LGADChargeSharing. I've always considered testing cellID with position converter and see if it throws error is a bit of a hack. I did not know m_seg.neighbours exist at all.

What's the problem you're facing, if you don't mind me asking? I think it is a nice improvement over the original LGADChargeSharing. I've always considered testing cellID with position converter and see if it throws error is a bit of a hack. I did not know m_seg.neighbours exist at all.

It's the differences in the capybara I don't quite understand:
https://eicrecon.epic-eic.org/pr/1763/capybara/rec_dis_10x100_minQ2=0_craterlake/index.html#TOFBarrelADCTDC

I thought that the changes shouldn't make a difference to the number or charge of hits if the charge limit is set to 0. But it looks like there are significantly fewer hits being created.

The neighbours will only work if the sensor uses a segmentation in the geometry which may not always be the case (but probably always should be...). I don't believe this will account for the edges of sensors either, so a hit in the detector can probably spread outside the sensor.

Looks like the problem comes from the MultiSegmentation used for the BTOF. The dd4hep neighbours function doesn't return any cellIDs when it is used. If it is possible to recover which sub-segmentation was used for the specific CellID this might be fixable but I haven't looked yet.

@wdconinc Any idea on this new memory leak I've introduced or how to debug it?

@wdconinc Any idea on this new memory leak I've introduced or how to debug it?

I'm guessing it came in through eic/epic#842. I'm looking into it.

I'm happier with how this looks now, if this can be approved.

Looks like the TOF digitization is closer to 10% now.
A bit off topic but is converting hits into measurements taking 35% of the computation or has that been combined with the CKF itself running somehow?

The change in the epic geometry changed the reference sample between PRs which caused me some confusion but did highlight the bugs in the pulse generation.

A bit off topic but is converting hits into measurements taking 35% of the computation or has that been combined with the CKF itself running somehow?

It's not always clear or consistent. JANA2 works by producing inputs for factories just-in-time, through calls to other factories. So, if a factory needs to get another factory to do something, then it will sit there and the extra time will be counted against it. If the inputs are already available when a next factory runs, it will not get that extra cost in running time. This all depends on the order in which factories are activated, and janatop has not enough info in its structures to subtract the time spent in supplier factories.

Looking at https://github.com/eic/EICrecon/actions/runs/14996201580/job/42131377031?pr=1763#step:7:1365, there are a few unambiguous lines possible:

• any digitization step that takes a non-negligible amount of time will show us as a link from raw hits to sim hits, and will be exclusive timing in the digitization itself,
• any link that starts from the JEventProcessorPodio is (at worst) the total time it takes to produce that output (but some time can have been accounted already in other links).

So, from that output, I'd agree that 10% is spent in creating TOFBarrelADCTDC, and all its inputs. It seems like 7.4% of time is spent inside the factory that created TOFBarrelPulses and all its inputs, and 2.3% is then spent inside TOFBarrelSmoothPulses (by which time the input will already have been created, apparently).